Field of the Invention
This patent application claims the benefit under 35 U.S.C. §119(e) of presently pending U.S. Provisional Patent Application 60/574,954, entitled UNIFORM REFERENCES, filed on May 27, 2004, the entire teachings of which are incorporated herein by reference.
Description of the Related Art
When building computer software, change happens often. Due to the oft-occurring changes in the software development process, software developers have gravitated towards the use of software configuration management tools. Software configuration management refers to the set of activities that are designed to control change by identifying the work product in a software development cycle which is most likely to change, establishing relationships among the identified work product, defining mechanisms for managing different versions of the identified work product, controlling changes that are imposed upon the work product, and auditing and reporting the changes.
A software configuration management system can provide its users both with the ability to record every detail of components used in a software build, and also with the ability to completely recreate the build environment. This requires the software configuration management system to generate a completely accurate software bill-of-materials for a software build. Additionally, the software configuration management system must be able to free the user from the need to manually maintain and declare most build dependencies in order to improve build accuracy and development productivity.
Software configuration management tools often suffer from a lack of a uniform mechanism for references to objects and resources that span storage boundaries. Most notably, data backup and restore operations, integration, and object and file versioning remain vulnerable to disparate references. In this regard, restoring data to a different location is not possible due to hard coded paths in references to data. Integrations are brittle for the same reason: if files or databases move, many integration links may become broken. Finally, since versioning applies to items beyond simply source code, references must account for items that might be referenced from a view other than the one in which the reference was created.
In order to ensure that persistent references accurately identify the appropriate item in the presence of backup/restore, integration and versioning, it is important to address the following issues:                A reference must be able to identify any persistent logical item;        A reference to an item must not become broken if the component housing that item is moved or restored to a different location;        A reference to an item must not break if the item is put under version control; and,        A reference must be able to locate the version of the item in a specified view, not just in the view in which the reference was created.        
Most references will point to whatever version of an item that appears in a current view, but some references will refer to a particular version, for example, an activity change set can reference specific versions of an item. Some references will reference whatever item currently has a specified name, while other references point to the item in a view that corresponds to a particular artifact, irrespective of the name of the artifact. If a versioned database is to be incrementally loaded on demand, the reference to a database object must identify the file housing that object. Likewise, an item could be replicated, so a reference must be able to locate the local replica of the item, not just the replica to which the reference was originally created.